Re: [PATCHES] add darwin/osxpb support to cvs

>Next time you can make your patch with "diff -crN" so that you don't have
>to create a separate tarball.

No problem. I tried just doing a diff with cvs but wasn't able to get 
the -N option to work. This is the first time I've ever tried 
patching unix software so I'm sorry if it's a bit messy. Thanks for 
you help in getting it right.


>  > - the config.guess and config.sub files have been updated by apple to
>>  support their new os. i don't think these changes have been folded
>>  back in to the main archive yet
>
>I installed the latest ones from GNU which claim to support it according
>to the ChangeLog.

I'll try checking out the new versions and see if they work. I can 
send you a diff with the ones I have here if you want to see the 
additions Apple made.


>  > I've followed the BeOS example of including the necessary sem.h
>>  declarations in src/include/port/darwin.h. this is rather messy at the
>>  moment and can be dumped once apple releases a version of PB with sysv
>>  sem built into the kernel.
>
>The include/port/beos.h isn't really a shining example of how to do this. 
>This file is include *everywhere*, but we don't want to know about
>semaphores everywhere.  I'd prefer it if you use the QNX approach and
>symlink sem.h into an include directory (e.g., /usr/local/include/sys),
>since it's only temporary anyway.

I agree it's rather messy. I originally had just used the sym link in 
/usr/local/include, but as I said, some of the newer Darwin kernels 
have the sysv sem.h file already there and I was worried about people 
overwriting it. If you think it's fair to put this responsibility on 
the end user, I'm ok with that. I just thought it might be nice to 
check and see if the semaphore implementation was already there, and 
if not, build the necessary parts. I'll switch it back to the way it 
was.

>I'm also somewhat concerned about the dynloader.c because it's under the
>Apache license which has a funny advertisement clause.  Comments from
>someone?

I wondering about this too. I'll try emailing Wilfredo Sanchez and 
see if I can get the code outside the Apache license. This would 
probably be easiest.


>The compiler probably predefines something like __darwin__, which you
>should use.  You can find out with

It doesn't actually provide __darwin__ but as I mentioned in a 
previous post, Apple is suggesting people use __APPLE__ combined with 
__ppc__ or __i386__ for the different darwin builds. The section in 
s_lock.c should probably be changed to reflect this instead of using 
DARWIN_OS.


>And finally, what's up with this:
>
>CFLAGS='-O0 -g -traditional-cpp'
>
>?  What's wrong with the "modern-cpp"?

Apple's "modern-cpp" called cpp-precomp uses some strange parsing 
that breaks on several files in the postgresql build. They are still 
working on it apparently and are suggesting people simply use the 
-traditional-cpp flag when this happens instead of trying to update 
the files.

Thanks again for all your comments and suggestions.

Bruce